home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group95b.txt / 000046_icon-group-sender _Fri Jun 16 11:42:08 1995.msg < prev    next >
Internet Message Format  |  1995-09-18  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Fri, 16 Jun 1995 16:24:48 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: 16 Jun 1995 11:42:08 -0700
  4. From: scott@cs.arizona.edu (Scott E Gilbert)
  5. Message-Id: <3rsja0$2jm@lectura.CS.Arizona.EDU>
  6. Organization: University of Arizona CS Department, Tucson AZ
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <3rpcmd$ie0@canopus.cc.umanitoba.ca>, <3rqsq6$g9s@lectura.CS.Arizona.EDU>, <3rsf2v$1e@lectura.CS.Arizona.EDU>
  9. Subject: Re: Language features & behavior of &null (was Re: ICON vs Ted Nelson)
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. Dave Schaumann <dave@CS.Arizona.EDU> wrote:
  13. >In article <3rqsq6$g9s@lectura.CS.Arizona.EDU>,
  14. >Scott E Gilbert <scott@CS.Arizona.EDU> wrote:
  15. >>
  16. >>Ok, so lets spark up a thread of our own.  What are your least and most
  17. >>favorite features about Icon?  What would you change?
  18. >
  19. >Mostly what I don't like about Icon is some important (IMHO) things
  20. >are missing.  Most obviously, some general interface to system calls
  21. >would make Icon much more useful for programming in shell-script
  22. >situations.  Also, it would be nice if Icon had some facility for
  23. >writing large programs (ie, name space control, inline functions,
  24. >enumerated types, real booleans, etc).
  25. >
  26.  
  27. Well, I sort of agree.  I'd like to see a new top level declaration to go
  28. aside "global" and "procedure" that would presumably be called "object", and
  29. then some scoping modifiers for inside this such as "private" or "hidden"
  30. and "public" or something like that.  Carry the OOP stuff far enough, and
  31. that would fix any concerns about "large" programs.  I'd also like to be
  32. able to nest procedure declarations.  All of this would make it a completely
  33. different language though.
  34.  
  35. As for system calls and what not, I'd like to see a documented and clean
  36. interface to things likes pipes and sockets.  I'm sure there is some hidden
  37. option to open() that will handle it, but I haven't seen it documented
  38. anywhere.
  39.  
  40. >
  41. >>Personally, I'd like to see the &null value act as a general purpose
  42. >>identity for all of the operators except when used as a procedure call.
  43. >
  44. >I disagree.  IMHO, this is one place where Icon got it right.  One of
  45. >my pet peeves is when some obscure default of a language hides an error
  46. >I've made by leaving something out.  If I've forgotton to initialize
  47. >a variable, I want to know it.
  48. >
  49.  
  50. You're one of those people who insists on using "local" inside of every
  51. procedure and compiling with the -u option aren't you.  :)  I personally
  52. just try to make every variable local, then you don't need to worry about it.
  53.  
  54. I guess this is just a style issue.  I tend to write lots of tiny procedures
  55. instead of fewer big ones, and that makes it difficult to lose track of what
  56. and where.  The one case where this hurts is typos.
  57.  
  58. What I hate is using a language where all of the type information is carried
  59. around for you at run time, but you still have to do stuff like:
  60.  
  61.   t:= table()
  62.   S:= set()
  63.   l:= list()
  64.   s:= ""
  65.  
  66. before you can build on anything.  I mean you might as well go back to
  67. declaring the type at the top of the procedure like you do in C or Pascal.
  68.  
  69.  
  70.  
  71.